Day06 - 一起來看 Kubernetes 官方文件吧！- Production environment 建議

16th鐵人賽 kubernetes

a259108736

2024-09-20 00:24:14

110 瀏覽

分享至

前言

在還沒開始正式安裝前，先來看看如何建立一個 “Production ready” 的 k8s cluster 吧

今日目標

了解官方 k8s 如何定義 Production 環境應該要有的條件

Production considerations

https://kubernetes.io/docs/setup/production-environment/

一般來說若是 Production 的環境，都會要求安全性 ↔ 方便使用，而這兩者間通常是互斥的。
舉個簡單的例子：防火牆設定之後可以提高安全性，但就會受到許多限制

官方列出了以下幾個大項：

Availability (可用性) ：要避免 single point of failure (SPOF) 的情況，而官方的建議為：
1. 將 control plane 與 worker nodes 拆開：也就是不要在 control plane 上面執行 workload
2. control plane 要使用多個 node (因為 Raft 演算法的關係，所以建議是 1 3 5 這樣擴增)
3. 透過 Load balancing 導流量至 API server (當有多 control plane node 時)
4. 確保有足夠的 worker nodes，或者有辦法快速的新增 worker node
Scale (擴展性)：要確保整座 k8s cluster 可以穩定的提供服務，而不只是 scale out，當淡季來臨時也可能會需要 scale in 以節省成本
Security and access management (安全性與權限管理)：當管理的人變多，就必須要分職責角色來管理 k8s cluster，以確保只有最核心的人員可以動到 k8s 內的核心資源。
可使用 k8s 內建的 role-based access control (RBAC) 機制，或者透過其他的實作來做到

核心的關鍵就是以上三點

此外官方文件也提供說不一定要自己建 k8s，也是可以考慮說使用公有雲的服務
https://kubernetes.io/docs/setup/production-environment/turnkey-solutions/
在上面的文件中，除了最常見的三大公有雲 (AWS, Azure, GCP) 以外，大約還有 50 多家雲端供應商提供 k8s 的服務 (仔細一看，AKS 與 Azure 居然分開兩項?)
關於使用雲端服務的好處，官方文件描述如下：

Serverless (無伺服器): 透過雲端商提供的 serverless 服務，就可以不用一直固定付機器的錢，可以用 CPU usage, memory, disk request 等等的用量來計費。另外的好處就是也不太需要考慮 scale in/out 的問題了
Managed control plane：把 control plane 交給雲端商控管，這樣就不需要處理太多 control plane 上的問題了
Managed worker nodes: 雲端商通常都會提供 scale worker node 的功能，只需要透過幾個按鈕就可以增加節點了
Integration( 整合)：k8s 有許多功能都是需要額外安裝套件才有的 (e.g. storage, logging, metrics 等等) ，而雲端商通常會提供相對應的服務串接使用

Production cluster setup

透過在不同的機器上架設 control plane 做到高可用，基本上就完成了一半。
以下分別以 control plane, worker nodes 兩項分別介紹

Production control plane

Choose deployment tools: 官方建議使用 kubeadm, kops, and kubespray 三套工具來部署，並且會選用不同的 CRI 來部署
Manage certificates (管理憑證)：control plane 之間都是透過 TLS 來溝通，以 kubeadm 工具部署來說，會自簽一整組的憑證來用。
若有額外需求，也可以指定自己機構簽發的 ca 憑證。
Configure load balancer for apiserver：上面有提過，在多個 apiserver 間要使用 load balancer 來做到流量負載高可用
Separate and backup etcd service：將 etcd 獨立存放，且持續備份。因為 etcd 是 control plane 的資料庫，因此 etcd 的可用性與效能直接決定了 k8s 的流暢度與可用度，考慮將 etcd 獨立到儲存裝置更好或網路傳輸更加的地方也不錯
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/ 透過 kubeadm 建立 etcd 的方式，可以單獨建立 etcd 在不同的機器上 (看起來也是透過 kubelet + static pods 的機制來做的)
Create multiple control plane systems：若是透過 init or systemd 帶起的 control plane 建議一定要 3 台以上，而若是以 kubelet + static pods 的機制的話，以 scheduler 為例，會透過 Raft 機制去進行選舉，因此若主服務消失，次要服務也會補上。
Span multiple zones (分布多區域)：在雲端商上通常會分成好幾個區域，可以把 k8s cluster 分別放在幾個區域中，避免當某個區域故障時服務就不可用。
若是實體機房，則可能部署在不同的地理位置，不同機櫃上等等，以做到避免單區域失效的情況。不過這部分不容易，光是網路的配置部分就不單純，也有另外的文件提供如何跑跨 zones 的 clsuter: https://kubernetes.io/docs/setup/best-practices/multiple-zones/
Manage on-going features:：後續的維運工作準備，最常遇到的就是憑證的更新作業，以 kubeadm 來說，是有提供指令可以處理，還有更新作業等等，都是在 k8s 管理必須的任務。

control plane 的各元件如何做到高可用，也都有另外的頁面解釋

Production worker nodes

wokrer nodes 與服務息息相關，配置上要注意：

Configure nodes：使用實體機或者虛擬機，並且安裝上合適的 OS
- 滿足 workload 的需求，包含 CPU, memory, disk 速度與足夠的儲存空間
- 是否需要 GPU，或者需求 windows nodes (通常是要跑一些 windows 專屬的 APP，例如 IIS 等)
Validate nodes (驗證節點)：透過 Valid node setup 頁面確保 nodes 上面都符合可 join cluster 的設定了
Add nodes to the cluster：準備新增 worker nodes 到 cluster 中的方法，如何至 apiserver 註冊等
Scale nodes：在比較大型的 k8s cluster 中，需要評估看看節點的規模，在 k8s 上面有一些硬限制 (e.g. 每個 node 上面不能跑超過 110 個 pods)，評估合適需要購買硬體設備等等。
Autoscale nodes (自動擴展節點)：在 k8s 中有個 cluster api 可用，通常是在雲端商比較容易使用，而地端則需要準備虛擬化平台才有機會做到。
Set up node health checks：定期的檢查 node 的健康程度，可以使用官方提供的工具 (node-problem-detector，但我沒用過，之後或許可以來寫寫，挺有趣的)：https://kubernetes.io/docs/tasks/debug/debug-cluster/monitor-node-health/

Set limits on workload resources

確保 workload 的設計有符合 HA 等等的機制也是很重要的：

Set namespace limits: k8s 是以 namespace 作為每個 AP 的區隔，可以針對 namespace 去設定限制只能使用最多多少的 CPU, memory 運算資源，這樣可以避免單一專案使用過量的資源影響到其他專案
另外還介紹了一個沒看過的東西： hns https://kubernetes.io/blog/2020/08/14/introducing-hierarchical-namespaces/，看起來是 2020 年左右就推出了，或許也值得研究看看…
Prepare for DNS demand：當 workload 越來越多，也可以考慮把 cluster 內的 DNS service (目前通常都是使用 coredns 實作) 自動擴展
Create additional service accounts：在每個 namespace 中，都會有預設的 service account 提供使用，建議每一個 pods 都要使用不同的 service account，主要是為了：
- 新增拉取 image 的倉庫需要登入時，可以把憑證放到 secret 內
- 提供 RBAC 給 service account，這樣可以確保不同 AP 的權限都受到不同的控管